Not applicable.
The present invention relates to the collection, storage and retrieval of data on computer systems. More particularly, the present invention relates to a method and apparatus for specifying address formats and rule sets for creating address formats for use throughout an information enterprise which facilitate automatic address building and storage for collected records and automatic generation of hyperlinks to stored records via database literate processors.
An exemplary information enterprise includes at least one database (DB), information collecting devices (ICDs) for collecting information to form data records for storage on the DB and one or more processors linked to the DB for running application programs which access and manipulate DB records. For example, U.S. patent application Ser. No. 09/170,169 filed Oct. 13, 1998 now pending (hereinafter xe2x80x9cthe ""169 applicationxe2x80x9d) entitled xe2x80x9cData Collection Device and System,xe2x80x9d which is commonly owned by the applicant of this application, describes several remote ICD types which collect information and provide the information and corresponding addresses to a DB for storage. For the purposes of this explanation ICDs may also include stationary computers or the like for data entry. U.S. patent application Ser. No. 09/247,349 filed Feb. 6, 1999 now pending (hereinafter xe2x80x9cthe ""349 application) entitled xe2x80x9cMethod and System for Automated Data Storage and Retrievalxe2x80x9d which is commonly owned by the applicant of this application, describes a database literate processor application program which automatically builds database addresses for forming hyperlinks between data references to records and the records referenced by the data references. The ""349 application also teaches processors which receive information sets and based on set content, generate DB addresses for the sets and store the information sets at the generated addresses. Although the invention may be used with other application programs, to simplify this explanation the invention will be described in the context of the DB literate processor program referenced above. Hereafter DB literate processor is taken to mean any of several different types of data processors including a word processor, a spread sheet, a data entry form and so on.
The proliferation of information systems throughout all aspects of business and personal life is a clear sign that society has recognized the advantages associated with such systems. Nevertheless, conventional information systems are plagued by a number of important shortcomings which render systems difficult to use and therefore, in many cases, underutilized.
First, in most cases it is extremely difficult to develop and maintain an entire information system which is completely information compatible. Information compatibility means that when a record and a corresponding address are provided to the DB for storage, the record information is arranged in a record format required by the DB and the record address is in an address format required by the DB. Information compatibility also means that when a DB literate program identifies a DB record in a record request, the request includes an address format which is recognizable by the DB.
Generally there are two ways to facilitate information compatibility. First, each ICD program and DB literate program may be programmed to provide records and respective storage addresses in record formats and address formats required by the DB. Second, an intermediate computer may be provided which receives information from ICDs and DB literate programs and uses the received information to generate records and respective storage addresses which comport with required DB record and address formats. The intermediate computer effectively operates as a translator between the ICDs and DB literate programs on one hand and the DB on the other hand.
In either case, after a DB characterized by record formats and address formats has been defined, additional custom programming has to be done to support information compatibility. In systems which do not include an intermediate computer, each ICD program and DB literate program has to be programmed to support information compatibility. In the case of an ICD program, this means that the program can recognize information required to form a record and an address, can identify the required information and can assemble the address and record for delivery to the DB. In the case of a DB literate program, this means that the program can recognize a reference to a stored record, can recognize information required to form an address for the referenced record, can identify the required information and can assemble an address for the referenced record. In systems which include an intermediate computer, the computer has to be programmed to receive information from the ICDs and application programs, recognize information required to form a record and/or an address, identify the required information and assemble the record and/or address for delivery to the DB.
Thus, programming an ICD, a DB literate program, or an intermediate computer requires provision of DB address formats and record formats and rule sets for identifying required information to instantiate the formats, rule sets for how to use the identified information to instantiate the formats often including specific information forms and rules for converting the identified information into the specific information forms.
Therefore, conventional systems for defining DB address formats and record formats require at least two programming steps to facilitate information compatibility including DB definition and additional programming of either ICD programs and DB literate programs or additional programming of an intermediate computer.
While two step programming is not particularly difficult where ICDs and application programs are only used with one DB and where the DB only supports one record format and one address format, most information systems include several DBs and each DB typically supports several different record formats and address formats. In addition, most information systems also include many different ICD and application program types, each of which may internally format information in a unique manner and may provide information to an intermediate computer in a unique configuration. These different ICD and application program types further increase programming complexity.
This smorgasbord of different DBs, record formats, address formats, ICD types and application program types is due to the evolutionary nature of information systems generally. Typically information systems grow and expand along with the businesses they serve. For example, an initial system may include one type of ICD and a single application, each of which is supportable by a single programming language. As technology evolves a second ICD type may be developed and added to the system, the second ICD type having to be programmed for DB information compatibility and so on. Similarly, as a business expands, database requirements eventually exceed existing capacity and additional DBs have to be added to the information system. Many times a new DB requires different record formats and address formats. In addition, often different ICDs and applications only support a vendors proprietary software and record and addressing formats.
The second shortcoming of conventional information systems is related closely to the first and is that highly skilled programmers are typically required to facilitate information compatible programming. This is because such programming requires an intimate knowledge of DB record formats and address formats and the form in which ICDs internally store information. In addition, in systems which do not include an intermediate computer, the programmer must have knowledge about the ICD and DB literate program programming languages. In systems which have an intermediate computer the programmer must have knowledge about the intermediate computers programming language. The task of programming is further exacerbated in most cases as most information systems include many different ICD types, application program types and DBs having unique programming characteristics as described above.
Third, modifications to information systems are relatively difficult to implement. Consider the case where a new record format and a new address format are added to a DB or the case where an entirely new DB is added to an information system where the new DB requires new address formats and record formats. In either of these two cases additional customizing programming is required. In systems which do not include an intermediate computer each ICD program and each DB literate program has to be modified to accommodate the new DB record format(s) and address format(s). Also, new rule sets for identifying required information and for instantiating address formats and record formats have to be provided to each ICD and each DB literate program. In systems which include an intermediate computer the intermediate computer has to be reprogrammed to accommodate the new DB record format(s) and address format(s).
Fourth, because highly skilled programmers are required to support and maintain an information system and many businesses do not employ such programmers, often, despite a systems ability to support additional information gathering, storage, retrieval and processing capabilities, a business will not take advantage of such additional capabilities.
For example, in a medical facility ICDs including bar code readers may routinely be used to memorialize physician visits to patients. With a bar coded bracelet on each patient, at the beginning of each patient visit a physician may be required to use the ICD to read the patient""s information from the bracelet. The ICD then generates a record including date, time, patient ID, physician ID and so on documenting a patient encounter. The ICD also generates a record address and, when downloaded to a DB, the DB stores the record at the corresponding address.
In this case, it may be advantageous to use the same bar code reading ICD to track other facility information. For example, facility equipment may be bar coded to track location of mobile equipment, medication containers may be bar coded when filled to track dispensation and so on. If the ICDs are used to track equipment location without custom programming equipment locations will be mistaken for patient encounters. Thus, custom programming is required. In this case, while the ICD may be ideal for other facility purposes, the programming task required to support these other capabilities may be prohibitively complex and therefore the additional capabilities may never be realized.
Fifth, especially in systems which include a large number of different devices, applications and DBS, program errors are extremely likely and, unfortunately, because of system complexity debugging is extremely difficult. For example, in the case of an ICD which generates both a data record and a corresponding address for the record from an information set and then downloads the record/address to a DB for storage, if a new record/address format pair is to be supported and each of the ICD and DB have to be programmed to support the new format separately, errors or incompatibilities between the DB and ICD are likely and identifying the errors would be difficult at best.
Therefore, it would be advantageous to have a method and apparatus which could be used to simplify the process of programming all of the components of an information system such that complete information compatibility can be achieved through a single programming process. It would also be advantageous if such a method and/or apparatus could ensure information compatibility.
The present invention is to be used with a system which includes at least one and perhaps several different types of processing devices, each processing device capable of either generating a storage address for a record or generating and creating a link to record stored at a particular address or both storing and linking. To this end, each processing device requires, among other things, a database address format which can be used as a pattern for generate the storage or linking address.
The invention includes both a method and an apparatus for specifying enterprise wide address formats for the use by all processing devices for address generating purposes. To this end, the inventive method includes the steps of specifying required address formats including a plurality of fields, for each format field, specifying a field type and providing the address format to the processing devices for storing and linking processes. To facilitate field type specification, the system preferably includes pre-defined field types which have been designed specifically for the facility which employs the invention and which, to that end, are defined to be the field types most likely to be routinely used at the facility.
In systems including many different types of processing devices, by specifying address formats once and then providing the formats to all processing devices, complete enterprise wide address compatibility is ensured.
In addition to including pre-defined address format field types, the invention also provides an instantiation rule set for each pre-defined field type which includes rules for identifying information to fill in or xe2x80x9cpopulatexe2x80x9d the corresponding field. For example, for a date field, the instantiation rule set indicates how to determine (e.g., the date format) in the address. As another example, for an xe2x80x9cECGxe2x80x9d field, the instantiation rule set indicates how to determine if an information set or a data reference corresponds to an ECG and if so, how to format an ECG type address format for storage or linking purposes.
It has been recognized that in a completely information compatible system there are at least two common information threads which are present in the software required to operate each system DB, device and application and that, by providing tools and methods which exploit these common information threads, the processes of defining, maintaining and modifying DB record and address formats and associated rules can be simplified appreciably. By simplifying the DB management tasks, DB management can be accomplished by less skilled administrators, in less time and can take full advantage of all DB capabilities.
The two common information threads are unique field instantiation rule sets (IRSs) and data type definitions. With respect to field IRSs, virtually all records and corresponding addresses can be divided into distinct fields. For instance, an exemplary universal resource locator (URL) address comporting with the well-known hypertext markup language (HTML) of the Internet, for a medication administration record for a specific patient at a specific time is:
xe2x80x9chttp://hww.st_mary.springfield/medication/given/987654321/19xe2x80x9405xe2x80x941996/13: 42/report.htmlxe2x80x9d (hereinafter xe2x80x9cthe exemplary addressxe2x80x9d)
Where xe2x80x9chttp://hww.st_mary.springfieldxe2x80x9d corresponds to a first field, xe2x80x9cmedication/givenxe2x80x9d corresponds to a second field, xe2x80x9c987654321xe2x80x9d corresponds to a third field and indicates a patient ID number, xe2x80x9c19xe2x80x9405xe2x80x941996xe2x80x9d corresponds to a fourth field and indicates a date, xe2x80x9c13:42xe2x80x9d indicates a time and corresponds to a fifth field and xe2x80x9creport.htmlxe2x80x9d corresponds to a sixth field and indicates the record type stored at the address. For each field in the exemplary address, a data object having a specific form has to be provided to instantiate the field. Hereinafter, although many types of data objects (e.g. text, other characters, binary codes, etc.) may be used to instantiate a field, the invention will be described as using ASCII text character strings to instantiate fields. In addition, a field specific rule set for identifying information to instantiate the field has to be provided. Moreover, in many cases, a second rule set, referred to herein as a conversion rule set, has to be provided for converting identified information into the specific form required for instantiation. Obviously, specifying all of this information for each field in each address format supported by a system is an arduous task.
However, the common field IRS thread is that most fields and corresponding IRSs (i.e. required field string gleaning rules and conversion rules) are used repetitively in many different address and record formats. This is particularly true in the case of a specialized facility where most information can generally be grouped by one or a small number of information segments. For example, in the case of the patient ID field (i.e. xe2x80x9c987654321xe2x80x9d) in the exemplary address above, a large number of records and corresponding addresses at medical facility will include a patient ID field. Therefore, if an IRS is specified once for a patient ID field and is then stored as a xe2x80x9cpre-definingxe2x80x9d field IRS, each time a patient ID field is required in an address or a record format, the pre-defining field IRS can be used. Similar pre-defining field IRSs can be provided for date, time, report type, server location, event (e.g. medication/given, post-op_ecg, etc.) physician identification, and so on.
Thus, the present invention provides a method and apparatus for, in effect, xe2x80x9cpre-definingxe2x80x9d field IRSs which, therefore, can be used to easily and quickly specify new address and record formats.
In addition to expediting DB management tasks, pre-defining field IRSs force system wide information compatibility and thereby reduce and, in many cases, will even eliminate debugging requirements. This is because, after unique field IRS have been specified once, those unique IRSs are used for specific corresponding fields thereafter and hence every time the corresponding field is employed, the same field character string and rules are employed.
With respect to the data type definitions common thread, a data type definition includes standard data type definition information such as information defining the structure and type of information stored in the specific data type and defining relationships between the specific data type and other data types common to conventional data type definitions. In addition, according to an exemplary embodiment of the present invention, the data type definition also includes an address format, a record format and a unique data reference (DR) where the DR is used to refer to a record of the specific data type.
Typically, each of a system DB and at least one and more often many system devices and applications require at least a subset of data type definition information. Therefore, after being specified once, the data type definitions can simply be provided once to a relevant system DB and corresponding devices and applications. Thus, the present invention also provides a method and apparatus for specifying data type definitions, earmarking certain sections of each data type definition for provision to specific devices and applications and then downloading earmarked sections to the devices and applications.
Thus, one object of the invention is to provide a system including predefined address format fields and corresponding instantiation rule sets which can be used to quickly define address formats for use by an enterprise computing system.
Another object is to provide a system wherein address formats can be specified once for all processing devices (e.g. databases, servers, applications, data collection devices, etc.). In addition to reducing the time and effort required to support a new address format, this feature ensures enterprise wide address formatting compatibility.
These and other objects, advantages and aspects of the invention will become apparent from the following description. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made therefor, to the claims herein for interpreting the scope of the invention.